<div class="tmd-doc">
<h1 class="tmd-header-1">
Expression Evaluation Orders
</h1>
<p></p>
<div class="tmd-usual">
This article will explain <a href="expressions-and-statements.html">expression</a> evaluation orders in all kinds of scenarios.
</div>
<p></p>
<p></p>
<h3 class="tmd-header-3">
An Expression Is Evaluated After the Expressions It Depends on
</h3>
<p></p>
<div class="tmd-usual">
This is easy to comprehend. An apparent example is an expression is evaluated later than its sub-expressions. For example, in a function call <code class="tmd-code-span">f(x, y[n])</code>,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">f()</code> is evaluated later than its depended expressions, including <code class="tmd-code-span">f</code>, <code class="tmd-code-span">x</code> and <code class="tmd-code-span">y[n]</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the evaluation of the expression <code class="tmd-code-span">y[n]</code> is later than the evaluations of <code class="tmd-code-span">n</code> and <code class="tmd-code-span">y</code>.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
Please read <a href="packages-and-imports.html#initialization-order">program code element initialization order</a> for another example on package-level variable initialization orders.
</div>
<p></p>
<p></p>
<h3 id="package-level-variables" class="tmd-header-3">
Initialization Order of Package-Level Variables
</h3>
<p></p>
<div class="tmd-usual">
When a package is loaded at run time, Go runtime will try to initialize uninitialized package-level variables which have no dependencies on uninitialized variables, by their declaration order, until no variables are initialized in such a process. For a successfully compiled Go program, there should be no uninitialized variables after all such processes end.
</div>
<p></p>
<div class="tmd-usual">
Package-level variables appearing as blank identifiers are treated like any other variables in the initialization process.
</div>
<p></p>
<div class="tmd-usual">
For example, in the following program, variable <code class="tmd-code-span">a</code> depends <code class="tmd-code-span">b</code>, and variables <code class="tmd-code-span">c</code> and <code class="tmd-code-span">_</code> depend on <code class="tmd-code-span">a</code>. So
</div>
<ol class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
The first initialized variable is <code class="tmd-code-span">b</code>, which is the first package-level variable without dependencies on other package-level variables.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The second initialized variable is <code class="tmd-code-span">a</code>. After <code class="tmd-code-span">b</code> is initialized, <code class="tmd-code-span">a</code> is the first package-level variable without dependencies on uninitialized package-level variables.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The third and fourth initialized variables are <code class="tmd-code-span">_</code> and <code class="tmd-code-span">c</code>. After <code class="tmd-code-span">a</code> and <code class="tmd-code-span">b</code> are initialized, <code class="tmd-code-span">_</code> and <code class="tmd-code-span">c</code> both don't depend on uninitialized package-level variables.
</div>
</li>
</ol>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

var (
	_ = f()
	a = b / 2
	b = 6
	c = f()
)

func f() int {
	a++
	return a
}

func main() {
	fmt.Println(a, b, c) // 5 6 5
}
</code></pre>
<p></p>
<div class="tmd-usual">
The above program prints <code class="tmd-code-span">5 6 5</code>.
</div>
<p></p>
<p></p>
<p></p>
<div class="tmd-usual">
Multiple variables on the left-hand side of a variable specification initialized by single multi-valued expression on the right-hand side are initialized together. For example, for a package-level variable declaration <code class="tmd-code-span">var x, y = f()</code>, variables <code class="tmd-code-span">x</code> and <code class="tmd-code-span">y</code> will be initialized together. In other words, no other variables will be initialized between them.
</div>
<p></p>
<div class="tmd-usual">
A package-level variable declaration with multiple source value expressions will be disassembled into multiple single-source-value variable declarations before initializing all package-level variables. For example,
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var m, n = expr1, expr2
</code></pre>
<p></p>
<div class="tmd-usual">
is equivalent to
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var m = expr1
var n = expr2
</code></pre>
<p></p>
<div class="tmd-usual">
If hidden dependencies exist between variables, the initialization order between those variables is unspecified. In the following example (copied from Go specification),
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
the variable <code class="tmd-code-span">a</code> will be initialized after <code class="tmd-code-span">b</code> for sure,
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
but whether <code class="tmd-code-span">x</code> is initialized before <code class="tmd-code-span">b</code>, between <code class="tmd-code-span">b</code> and <code class="tmd-code-span">a</code>, or after <code class="tmd-code-span">a</code>, is not specified.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
and the moment at which function <code class="tmd-code-span">sideEffect()</code> is called (before or after <code class="tmd-code-span">x</code> is initialized) is also not specified.
</div>
</li>
</ul>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// x has a hidden dependency on a and b
var x = I(T{}).ab()
// Assume sideEffect is unrelated to x, a, and b.
var _ = sideEffect()
var a = b
var b = 42

type I interface    { ab() []int }
type T struct{}
func (T) ab() []int { return []int{a, b} }
</code></pre>
<p></p>
<div class="tmd-usual">
Please note that, Go specification doesn't compulsively specify the compilation order of the source files in a package, so try not to put some package-level variables into different source files in a package if there are complicate dependency relations between those variables; otherwise a variable might be initialzied to different values by different Go compilers.
</div>
<p></p>
<div class="tmd-usual">
And please be aware of that some Go Toolchain versions don't correctly implement the above rules described in the current section. For example:
</div>
<p></p>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="https://github.com/golang/go/issues/66575">a bug</a> in Go Toolchain 1.22.0 - 1.22.4.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="https://github.com/golang/go/issues/66585">a bug</a> in Go Toolchain versions prior to 1.23.
</div>
</li>
</ul>
<p></p>
<h3 class="tmd-header-3">
Operand Evaluation Orders in Logical Operations
</h3>
<p></p>
<div class="tmd-usual">
In a bool expression <code class="tmd-code-span">a &amp;&amp; b</code>, the right operand expression <code class="tmd-code-span">b</code> will be evaluated only if the left operand expression <code class="tmd-code-span">a</code> is evaluated as <code class="tmd-code-span">true</code>. So <code class="tmd-code-span">b</code> will be evaluated, if it needs to be evaluated, after the evaluation of <code class="tmd-code-span">a</code>.
</div>
<p></p>
<div class="tmd-usual">
In a bool expression <code class="tmd-code-span">a || b</code>, the right operand expression <code class="tmd-code-span">b</code> will be evaluated only if the left operand expression <code class="tmd-code-span">a</code> is evaluated as <code class="tmd-code-span">false</code>. So <code class="tmd-code-span">b</code> will be evaluated, if it needs to be evaluated, after the evaluation of <code class="tmd-code-span">a</code>.
</div>
<p></p>
<h3 class="tmd-header-3">
The Usual Order
</h3>
<p></p>
<div class="tmd-usual">
For the evaluations within a function body, Go specification says
</div>
<p></p>
<div class="tmd-quotation">
<div class="tmd-usual">
..., when evaluating the operands of an expression, assignment, or return statement, all function calls, method calls, and (channel) communication operations are evaluated in lexical left-to-right order.
</div>
</div>
<p></p>
<div class="tmd-usual">
The just described order is called <span class="tmd-bold"><span class="tmd-italic">the usual order</span></span>.
</div>
<p></p>
<div class="tmd-usual">
Please note that an explicit value conversion <code class="tmd-code-span">T(v)</code> is not a function call.
</div>
<p></p>
<div class="tmd-usual">
For example, in an expression <code class="tmd-code-span">[]int{x, fa(), fb(), y}</code>, assume <code class="tmd-code-span">x</code> and <code class="tmd-code-span">y</code> are two variables, <code class="tmd-code-span">fa</code> and <code class="tmd-code-span">fb</code> are two functions, then the call <code class="tmd-code-span">fa()</code> is guaranteed to be evaluated (executed) before <code class="tmd-code-span">fb()</code>. However, the following the evaluation orders are unspecified in Go specification:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
the evaluation order of <code class="tmd-code-span">x</code> (or <code class="tmd-code-span">y</code>) and <code class="tmd-code-span">fa()</code> (or <code class="tmd-code-span">fb()</code>).
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the evaluation order of <code class="tmd-code-span">x</code>, <code class="tmd-code-span">y</code>, <code class="tmd-code-span">fa</code> and <code class="tmd-code-span">fb</code>.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
Another example, the following assignment, is demoed in Go specification.
</div>
<p></p>
<pre class="tmd-code disable-line-numbers111">
<code class="language-go">y[z.f()], ok = g(h(a, b), i()+x[j()], &lt;-c), k()
</code></pre>
<p></p>
<div class="tmd-usual">
where
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">c</code> is a channel expression and will be evaluated to a channel value.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">g</code>, <code class="tmd-code-span">h</code>, <code class="tmd-code-span">i</code>, <code class="tmd-code-span">j</code> and <code class="tmd-code-span">k</code> are function expressions.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">f</code> is a method of expression <code class="tmd-code-span">z</code>.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
Also considering the rule mentioned in the last section, compilers should guarantee the following evaluation orders at run time.
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
The function calls, method calls and channel communication operations happen in the order <code class="tmd-code-span">z.f()</code>→<code class="tmd-code-span">h()</code>→<code class="tmd-code-span">i()</code>→<code class="tmd-code-span">j()</code>→<code class="tmd-code-span">&lt;-c</code>→<code class="tmd-code-span">g()</code>→<code class="tmd-code-span">k()</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">h()</code> is evaluated after the evaluations of expressions <code class="tmd-code-span">h</code>, <code class="tmd-code-span">a</code> and <code class="tmd-code-span">b</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">y[]</code> is evaluated after the evaluation of <code class="tmd-code-span">z.f()</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">z.f()</code> is evaluated after the evaluation of expression <code class="tmd-code-span">z</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">x[]</code> is evaluated after the evaluation of <code class="tmd-code-span">j()</code>.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
However, the following orders (and more others) are not specified.
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
The evaluation order of <code class="tmd-code-span">y</code>, <code class="tmd-code-span">z</code>, <code class="tmd-code-span">g</code>, <code class="tmd-code-span">h</code>, <code class="tmd-code-span">a</code>, <code class="tmd-code-span">b</code>, <code class="tmd-code-span">x</code>, <code class="tmd-code-span">i</code>, <code class="tmd-code-span">j</code>, <code class="tmd-code-span">c</code> and <code class="tmd-code-span">k</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The evaluation order of <code class="tmd-code-span">y[]</code>, <code class="tmd-code-span">x[]</code> and <code class="tmd-code-span">&lt;-c</code>.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
By the usual order, we know the following declared variables <code class="tmd-code-span">x</code>, <code class="tmd-code-span">m</code> and <code class="tmd-code-span">n</code> (also demoed in Go specification) will be initialized with ambiguous values.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">	a := 1
	f := func() int { a++; return a }

	// x may be [1, 2] or [2, 2]: evaluation order
	// between a and f() is not specified.
	x := []int{a, f()}

	// m may be {2: 1} or {2: 2}: evaluation order
	// between the two map element assignments is
	// not specified.
	m := map[int]int{a: 1, a: 2}

	// n may be {2: 3} or {3: 3}: evaluation order
	// between the key and the value is unspecified.
	n := map[int]int{a: f()}
</code></pre>
<p></p>
<h3 id="value-assignment" class="tmd-header-3">
Evaluation and Assignment Orders in Assignment Statements
</h3>
<p></p>
<div class="tmd-usual">
Beside the above introduced rules, Go specification specifies more on the expression evaluation order the order of individual assignments in an assignment statement:
</div>
<p></p>
<div class="tmd-quotation">
<div class="tmd-usual">
The assignment proceeds in two phases. First, the operands of index expressions and pointer indirection (including implicit pointer indirection in selectors) on the left and the expressions on the right are all evaluated in the usual order. Second, the assignments are carried out in left-to-right order.
</div>
</div>
<p></p>
<div class="tmd-usual">
Later, we may call the first phase as evaluation phase and the second phase as carry-out phase.
</div>
<p></p>
<div class="tmd-usual">
Go specification doesn't specify clearly whether or not the assignments carried-out during the second phase may affect the expression evaluation results got in the first phase, which ever caused <a href="https://github.com/golang/go/issues/23188#issuecomment-403951267">some</a> <a href="https://github.com/golang/go/issues/15620">disputes</a>. So, here, this article will explain more on the evaluation orders in value assignments.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
Firstly, let's clarify that the assignments carried-out during the second phase don't affect the expression evaluation results got at the end of the first phase.
</div>
<p></p>
<div class="tmd-usual">
To make the following explanations convenient, we assume that the container (slice or map) value of an index destination expression in an assignment is always addressable. If it is not, we can think the container value has already been saved in and replaced by a temporary addressable container value before carrying out the second phase.
</div>
<p></p>
<div class="tmd-usual">
At the time of the end of the evaluation phase and just before the carry-out phase starts, each destination expression on the left of an assignment has been evaluated as its elementary form. Different destination expressions have different elementary forms.
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
If a destination expression is a blank identifier, then its elementary form is still a blank identifier.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
If a destination expression is a container (array, slice or map) index expression <code class="tmd-code-span">c[k]</code>, then its elementary form is <code class="tmd-code-span">(*cAddr)[k]</code>, where <code class="tmd-code-span">cAddr</code> is a pointer pointing to <code class="tmd-code-span">c</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
For other cases, the destination expression must result an addressable value, then its elementary form is a dereference to the address of the destination expression evaluation result.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
Assume <code class="tmd-code-span">a</code> and <code class="tmd-code-span">b</code> are two addressable variables of the same type, the following assignment
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">	a, b = b, a
</code></pre>
<p></p>
<div class="tmd-usual">
will be executed like the following steps:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// The evaluation phase:
P0 := &amp;a; P1 := &amp;b
R0 := b; R1 := a 

// The elementary form: *P0, *P1 = R0, R1

// The carry-out phase:
*P0 = R0
*P1 = R1
</code></pre>
<p></p>
<div class="tmd-usual">
Here is another example, in which <code class="tmd-code-span">x[0]</code> instead of <code class="tmd-code-span">x[1]</code> is modified.
</div>
<p></p>
<pre class="tmd-code line-numbers must-line-numbers">
<code class="language-go">	x := []int{0, 0}
	i := 0
	i, x[i] = 1, 2
	fmt.Println(x) // [2 0]
</code></pre>
<p></p>
<div class="tmd-usual">
The decomposed execution steps for the line <span class="tmd-italic">3</span> shown below are like:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// The evaluation phase:
P0 := &amp;i; P1 := &amp;x; T2 := i
R0 := 1; R1 := 2
// Now, T2 == 0

// The elementary form: *P0, (*P1)[T2] = R0, R1

// The carry-out phase:
*P0 = R0
(*P1)[T2] = R1
</code></pre>
<p></p>
<div class="tmd-usual">
An example which is a little more complex.
</div>
<p></p>
<pre class="tmd-code line-numbers must-line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	m := map[string]int{"Go": 0}
	s := []int{1, 1, 1}; olds := s
	n := 2
	p := &amp;n
	s, m["Go"], *p, s[n] = []int{2, 2, 2}, s[1], m["Go"], 5
	fmt.Println(m, s, n) // map[Go:1] [2 2 2] 0
	fmt.Println(olds)    // [1 1 5]
}
</code></pre>
<p></p>
<div class="tmd-usual">
The decomposed execution steps for the line <span class="tmd-italic">10</span> shown below are like:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// The evaluation phase:
P0 := &amp;s; PM1 := &amp;m; K1 := "Go"; P2 := p; PS3 := &amp;s; T3 := 2
R0 := []int{2, 2, 2}; R1 := s[1]; R2 := m["Go"]; R3 := 5
// now, R1 == 1, R2 == 0

// The elementary form:
//     *P0, (*PM1)[K1], *P2, (*PS3)[T3] = R0, R1, R2, R3

// The carry-out phase:
*P0 = R0
(*PM1)[K1] = R1
*P2 = R2
(*PS3)[T3] = R3
</code></pre>
<p></p>
<div class="tmd-usual">
The following example rotates all elements in a slice for one index.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">	x := []int{2, 3, 5, 7, 11}
	t := x[0]
	var i int
	for i, x[i] = range x {}
	x[i] = t
	fmt.Println(x) // [3 5 7 11 2]
</code></pre>
<p></p>
<div class="tmd-usual">
Another example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">	x := []int{123}
	x, x[0] = nil, 456        // will not panic
	x, x[0] = []int{123}, 789 // will panic
</code></pre>
<p></p>
<div class="tmd-usual">
Although it is legal, it is not recommended to use complex multi-value assignments in Go, for their readabilities are not good and they have negative effects on both compilation speed and execution performance.
</div>
<p></p>
<div class="tmd-usual">
As mentioned above, not all orders are specified in Go specification for value assignments, so some bad written code may produce different results. In the following example, the expression order of <code class="tmd-code-span">x+1</code> and <code class="tmd-code-span">f(&amp;x)</code> is not specified. So the example may print <code class="tmd-code-span">100 99</code> or <code class="tmd-code-span">1 99</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	f := func (p *int) int {
		*p = 99
		return *p
	}

	x := 0
	y, z := x+1, f(&amp;x)
	fmt.Println(y, z)
}
</code></pre>
<p></p>
<div class="tmd-usual">
The following is another example which will print ambiguous results. It may print <code class="tmd-code-span">1 7 2</code>, <code class="tmd-code-span">1 8 2</code> or <code class="tmd-code-span">1 9 2</code>, depending on different compiler implementations.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	x, y := 0, 7
	f := func() int {
		x++
		y++
		return x
	}
	fmt.Println(f(), y, f())
}
</code></pre>
<p></p>
<h3 class="tmd-header-3">
Expression Evaluation Orders in <code class="tmd-code-span">switch-case</code> Code Blocks
</h3>
<p></p>
<div class="tmd-usual">
The expression evaluation order in a <code class="tmd-code-span">switch-case</code> code block has been <a href="control-flows.html#switch-case">described before</a>. Here just shows an example. Simply speaking, before a branch code block is entered, the <code class="tmd-code-span">case</code> expressions will be evaluated and compared with the switch expression one by one, until a comparison results in <code class="tmd-code-span">true</code>.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	f := func(n int) int {
		fmt.Printf("f(%v) is called.\n", n)
		return n
	}

	switch x := f(3); x + f(4) {
	default:
	case f(5):
	case f(6), f(7), f(8):
	case f(9), f(10):
	}
}
</code></pre>
<p></p>
<div class="tmd-usual">
At run time, the <code class="tmd-code-span">f()</code> calls will be evaluated by the order from top to bottom and from left to right, until a comparison results in <code class="tmd-code-span">true</code>. So <code class="tmd-code-span">f(8)</code>, <code class="tmd-code-span">f(9)</code> and <code class="tmd-code-span">f(10)</code> will be not evaluated in this example.
</div>
<p></p>
<div class="tmd-usual">
The output:
</div>
<pre class="tmd-code output">
f(3) is called.
f(4) is called.
f(5) is called.
f(6) is called.
f(7) is called.
</pre>
<p></p>
<h3 class="tmd-header-3">
Expression Evaluation Orders in <code class="tmd-code-span">select-case</code> Code Blocks
</h3>
<p></p>
<div class="tmd-usual">
When executing a <code class="tmd-code-span">select-case</code> code block, before entering a branch code block, all the channel operands of receive operations and the operands of send statements involved in the <code class="tmd-code-span">select-case</code> code block are evaluated exactly once, in source order (from top to bottom, from left to right).
</div>
<p></p>
<div class="tmd-usual">
Note, the target expression being assigned to by a receive <code class="tmd-code-span">case</code> operation will only be evaluated if that receive operation is selected later.
</div>
<p></p>
<div class="tmd-usual">
In the following example, the expression <code class="tmd-code-span">*fptr("aaa")</code> will never get evaluated, for its corresponding receive operation <code class="tmd-code-span">&lt;-fchan("bbb", nil)</code> will not be selected.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	c := make(chan int, 1)
	c &lt;- 0
	fchan := func(info string, c chan int) chan int {
		fmt.Println(info)
		return c
	}
	fptr := func(info string) *int {
		fmt.Println(info)
		return new(int)
	}

	select {
	case *fptr("aaa") = &lt;-fchan("bbb", nil): // blocking
	case *fptr("ccc") = &lt;-fchan("ddd", c):   // non-blocking
	case fchan("eee", nil) &lt;- *fptr("fff"):  // blocking
	case fchan("ggg", nil) &lt;- *fptr("hhh"):  // blocking
	}
}
</code></pre>
<p></p>
<div class="tmd-usual">
The output of the above program:
</div>
<pre class="tmd-code output">
bbb
ddd
eee
fff
ggg
hhh
ccc
</pre>
<p></p>
<div class="tmd-usual">
Note that the expression <code class="tmd-code-span">*fptr("ccc")</code> is the last evaluated expression in the above example. It is evaluated after its corresponding receive operation <code class="tmd-code-span">&lt;-fchan("ddd", c)</code> is selected.
</div>
<p></p>
<p></p>
</div>
